The identity and authenticity of programs stored and running on a computer system is a fundamental security issue for users. Essentially, users want the programs they interact with and that operate on their behalf to perform as the program is advertised. Users may encounter problems when they trust a specific program, but the program behaves in an unexpected way. In some situations, the program may have been deliberately altered, or a virus or other security issue may be present. More often than not, the program simply behaves differently than the user initially expected because it does not come from a trusted source, it has been altered at some point rendering it incompatible with other components, or it is ineffective for whatever reason.
Current operating systems do not have consistent mechanisms for establishing and authenticating identities of programs. In Mac OS X, for example, many components are capable of storing paths, which are used to identify programs. Such a stored path is useful for determining if the program has been relocated from where the stored path indicates. However, the stored path does not bind the identity of the program, does not allow the program to be legitimately relocated (e.g., on non-local disk media), and does not address any alteration of the program after it was produced by the manufacturer.
In another example, other components of Mac OS X use bundle identifiers or other fields in an Info.plist of a program and trust these identifiers to establish the identity of the program. As is known, an Info.plist is an Information Property List File that is required for Mac OS X software programs packaged in the form of a bundle. The Info.plist contains key-value pairs that specify information used at runtime by the operating system and the software program that contains the property list. However, any benefit of identifying and authenticating the program using the bundle identifiers in the Info.plist can be easily circumvented when the Info.plist is copied and edited.
In yet another example, components of Mac OS X may use a keychain layer to establish the identity of programs and to assign access privileges to resources based on the identity of programs that are visible to the user. As is known, a Keychain is an encrypted container that holds Keychain items, which can be passwords, keys, certificates, text strings, and the like. Keychains can be used to manage the multiple passwords, keys, certificates, etc. that are needed in a computer system to access programs or to use secure services.
Because Keychains are secure storage containers, access to their contents cannot be obtained unless the Keychain is unlocked by a password or key. Once unlocked, trusted programs are allowed to access the keychain items contained in the Keychain. To allow access to trusted programs, the Keychain includes an Access Control List (ACL) layer that allows access to Keychain items based directly on what program is calling the Keychain. The ACL layer specifies what operations can be done with Keychain items, such as decrypting or authenticating, and specifies what trusted programs can perform the specified operations without authorization from the user. Accordingly, these trusted programs usually only need to call a Keychain Service API to store or retrieve Keychain items in an unlocked Keychain.
The Keychain layer in Mac OS X allows programs to be relocated if necessary and provides some tamper protection for the programs. However, the benefits of the Keychain layer for identifying programs may be lost whenever the program is altered (e.g., by software updates or the like). For example, the Keychain layer uses a hash scheme to recognize a program as being trusted for access to the Keychain items. If the program has been changed by an update or the like, then hash values for the updated program will not be recognized because they will not match the values in the Keychain layer. By default, the Keychain Services API automatically dialogs the user in this situation. In the dialog, the user is asked to recognize the updated program as being essentially the same as or different from the program when it was formerly trusted. Thus, the user must explicitly allow the updated program to access the implicated Keychain from then on. If a user's system receives multiple updates to multiple programs, repeated dialogs to the user are needed to grant the newly updated programs access to various Keychains. Not only does this have implications when a user's system is legitimately updated or changed, but there are also security implications involved when programs on a user's system are illegitimately changed or new programs are added that have or request access to Keychains.
In addition to the issues above, all these mechanisms blindly trust on-disk (static) code. Consequently, any properly timed modifications to on-disk code can attack program files after checks have been made, circumventing any benefits of these mechanisms. Furthermore, a redirection attack can fool the operating system into believing the wrong program is actually running. Finally, all these mechanisms rely on a very specific definition of what constitutes a “program” for identity purposes. Usually, a “program” is only an application bundle or only an executable file. Ancillary elements (e.g., AppleScripts, applets, widgets, etc.) may simply not register as a “program” with these mechanisms, or they may improperly register as a browser, a widget runner, an AppleScript interpreter, etc.
Consequently, a mechanism is needed for establishing and authenticating the identity of code in a number of forms while it is on disk and while it is running on a computer system. The subject matter of the present disclosure is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.